Generally, in the field of telecommunications, communication transmissions are facilitated by the use of communication platforms (e.g. relay stations). These communication platforms include any vehicle, manned or unmanned, that passes over, or hovers over a territorial coverage region, ranging from typical altitudes of manned and unmanned aircraft (UAVs) and lighter than air (LTA) platforms, to communication satellites in any orbit, not just of the Earth but of any celestial object such as the Moon or Mars.
Generally, these communication platforms have limited downlink telemetry bandwidth due to, for example, restricted radio frequency spectrum allocation. A large percentage of the allotted bandwidth for the communication platforms is consumed by overhead required by each communication data packet to follow various standards and layer protocols used in the telemetry system. This limited telemetry bandwidth and the required overhead results in inefficiencies in the actual telemetry data downlinked to, for example, a ground station. In conventional communication system designs, generally only one virtual channel is used per packet. As a result, in order to achieve the required packet size, fill data is inserted into the remaining bits. This fill data, generally consists of a set pattern of binary digits, and is considered part of the overhead, as its sole purpose is to fill the packet.
As a general example, many NASA (National Aeronautics and Space Administration) space programs use Consultative Committee for Space Data Systems (CCSDS) standards as the layer 2 protocols for the downlink telemetry data to the ground station. The CCSDS standards use a fixed size, packetized telemetry protocol scheme. However, as noted above, the CCSDS protocol consumes a large amount of overhead in the header information. Depending on the downlink transmission rate, a size of the Channel Access Data Unit (CADU) frame, and if there is any forward error correction required in order to maintain the link margin to the ground station, the typical CCSDS overhead consumed is between about 14% to about 50% in a CADU. Part of the inefficiency of the CCSDS formatted telemetry is due to, for example, the filled data used at the end of each Advanced Orbiting Systems (AOS) Transfer Frame in order to keep the fixed size packet. The size of the filled data is determined by the size of the actual payload. The filled data can be predicted if the raw data is a fixed size packet.
Most space communication applications have limited telemetry bandwidth due the spectrum allocation as noted above. A telemetry processing box for the space application receives flight instrumentation data from, for example, a computer or other data acquisition boxes, and packages the received data to the CCSDS format telemetry and downlinks it to the ground station in real time. The telemetry processing box is generally designed for short duration mission where the data is received and transmitted at the same time. A disadvantage of this conventional design is that the unsubscribed telemetry data will be consumed by the filled data in order to maintain the fixed size CADU packet.
Typically, CCSDS 133.1-B-2 is the encapsulation service that is used with conventional space data protocol service. As part of the CCSDS encapsulation service, each received completed payload frame has an encapsulation packet header inserted at the beginning of the payload. When the data field is less than the expected number of bytes of a CCSDS packet, one (or multiple of 1 byte) CCSDS packet(s) will be inserted into the data field to maintain the fixed size AOS transfer frame. Once the encapsulation service is complete, the encapsulated packet is then transferred using the AOS space data link protocol, such as specified in CCSDS 732.0-B-2, in a constant length AOS transfer frame. Generally, each type of telemetry is appended by a different virtual channel including header information, which the ground station receiver uses for differentiating telemetry types. The start of the AOS transfer frame is signaled by an underlying channel coding sub-layer which is specified by CCSDS 131.0-B-2. This start pattern is called the ASM sync marker. When for, example, a virtual channel ID is equal to a predetermined value, idle transfer frames are being transmitted. The idle transfer frames do not include user data in the transfer frame data field and the idle data or idle pattern in the transfer frame data field must not be confused with the idle packet specified as part of CCSDS 133.1-B-2.
Multiplexing Protocol Data Unit (M_PDU) or idle data is part of the transfer frame data field. The M_PDU is a 2 byte header where the first 5 bits are spare bits and a first header pointer is 11 bits. The first header pointer shall contain the position of the first byte of the encapsulation packet that starts in the M_PDU packet zone. The first byte of data in the M_PDU packet zone is assigned location 0. If no packet starts in the M_PDU packet zone then the first header pointer shall be set to all 1's (11′h7FF). This situation occurs when a long packet spans across multiple AOS transfer frames. In the case where no valid transfer frame data field is available for transmission at release time for an AOS transfer frame, an AOS transfer frame with a data field containing only idle data shall be transmitted. The VICD shall be set to all 1's and the project=specified idle patted is to be inserted. The first header pointer in this is then set to all 1's minus 1 (11′h7FE).
Upon completion of the AOS transfer frame, the telemetry box will append 1022 bits of a low-density parity-check code rate of 223/225 techniques in accordance with CCSDS 131.0-B-2, section 7.3, and there are two additional 0 filled bits added after the 1022 low-density parity-check code bits in order to form, for example, a 8160 bit codeword. The last step involved in CCSDS 131.0-B-2 attached a sync marker and pseudo-randomizes bits in the 8160 bit codeword to ensure sufficient bit transition density. This pseudo-randomization is accomplished by XOR each bit of the codeword with the output of a standard pseudo-random sequence. The pseudo-random sequence shall be generated using h(x)=x8+x7+x5+x3+1. This sequence continues for 255 cycles and repeats until end of the codeword. Note that the ASM sync marker is not randomized.
Accordingly, apparatus and method, intended to address the above-identified concerns, would find utility.